home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-cameron-tmux-01.txt < prev    next >
Text File  |  1993-10-07  |  15KB  |  450 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Internet Draft                                           P. Cameron
  8.                                        Xylogics, International Ltd.
  9.                                                          D. Crocker
  10.                                              Silicon Graphics, Inc.
  11.                                                        October 1993
  12.  
  13.               Transport Multiplexing Protocol (TMux)
  14.             (Internet draft: draft-cameron-tmux-01.txt)
  15.  
  16. Status of this Memo
  17.  
  18.    This document is an Internet Draft.  Internet Drafts are working
  19.    documents of the Internet Engineering Task Force (IETF), its
  20.    Areas, and its Working Groups.  Note that other groups may also
  21.    distribute working documents as Internet Drafts. Internet Drafts
  22.    are draft documents valid for a maximum of six months.
  23.    Internet Drafts may be updated, replaced, or obsoleted by other
  24.    documents at any time.  It is not appropriate to use Internet
  25.    Drafts as reference material or to cite them other than as a
  26.    "working draft" or "work in progress." Please check the I-D
  27.    abstract listing contained in each Internet Draft directory to
  28.    learn the current status of this or any other Internet Draft.
  29.  
  30.    It is intended that this document will be submitted to the IESG
  31.    for consideration as a standards document.  Distribution of this
  32.    document is unlimited.
  33.  
  34. Abstract
  35.  
  36.    One of the problems with the use of terminal servers is the
  37.    large number of small packets they can generate. Frequently,
  38.    most of these packets are destined for only one or two hosts.
  39.    TMux is a protocol which allows multiple short transport
  40.    segments, independent of application type, to be combined
  41.    between a server and host pair.
  42.  
  43. Acknowledgments
  44.  
  45.    This specification is the result of several discussions and
  46.    related initiatives through IETF working groups.
  47.  
  48.    (We have heard that Danny Cohen, of USC's ISI, suggested a
  49.    scheme like TMux about 8 years ago, but have not yet located the
  50.    reference.)
  51.  
  52. 1. Introduction
  53.  
  54.    When network designers consider which protocols generate the
  55.    most load, they naturally tend to consider protocols which
  56.    transfer large blocks of data (e.g. FTP, NFS).  What is often
  57.    not considered is the load generated by Telnet and Rlogin
  58.    because of the assumption that users type slowly and the packets
  59.    are very small.  This is a grave underestimation of the load on
  60.    networks and hosts which have many Telnet and Rlogin ports on
  61.  
  62.  
  63.  
  64. Cameron, Crocker         Expires: April 94                 [Page 1]
  65.  
  66.  
  67.  
  68. Internet Draft                  TMux                   October 1993
  69.  
  70.  
  71.    multiple terminal servers.
  72.  
  73.    The problem stems from the fact that the work a host must do to
  74.    process a 1-byte packet is very nearly as much as the work it
  75.    must do to process a 1500-byte packet.  That is, it is the
  76.    overhead of processing a packet which consumes a hosts
  77.    resources, not the processing of the data.
  78.  
  79.    If one assumes that most users connected to a terminal server
  80.    will be connecting to only a few hosts, then it should be
  81.    obvious that the network and host load could be greatly reduced
  82.    if traffic from multiple users, destined for the same host,
  83.    could be sent in the same packet.
  84.  
  85.    TMux is designed to improve network utilization and reduce the
  86.    interrupt load on hosts which conduct multiple sessions
  87.    involving many short packets.  It does this by multiplexing
  88.    transport traffic onto a single IP datagram, thereby resulting
  89.    in fewer, larger packets.  TMux is highly constrained in its
  90.    method of accomplishing this task, seeking simplicity rather
  91.    than sophistication.
  92.  
  93. 2. Protocol Design and Subconnection Messages
  94.  
  95.    IP hosts may engage in the use of TMux transparently, and may
  96.    even switch back and forth between use of TMux and carriage of
  97.    transport segments in the usual, independent IP datagrams.
  98.  
  99.    TMux operates by placing a set of transport segments into the
  100.    same IP datagram.  Each segment has a TMux mini-header which
  101.    specifies the segment length and the actual segment transport
  102.    protocol.  The receiving host demultiplexes the individual
  103.    transport segments and presents it to the transport layer as if
  104.    it had been received in the usual IP/transport packaging.  The
  105.    transport layer is, therefore, unaware of the special
  106.    encapsulation which was used.
  107.  
  108.    Hence, a TMux datagram appears as:
  109.  
  110.      | IP hdr | TM hdr | Tport segment | TM hdr | Tport segment| ...|
  111.  
  112.    Where:
  113.  
  114.  
  115.    TM hdr         is a TMux mini-header and specifies the following
  116.                   Tport segment.
  117.  
  118.  
  119.  
  120.    Tport segment  refers to the entire transport segment, including
  121.                   transport headers.
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128. Cameron, Crocker         Expires: April 94                 [Page 2]
  129.  
  130.  
  131.  
  132. Internet Draft                  TMux                   October 1993
  133.  
  134.  
  135. 2.1. IP Protocol field value
  136.  
  137.    TMux is indicated  in an IP datagram by the Protocol (ID) value
  138.    of XXXXX.
  139.  
  140.  
  141. 2.2. Header Format
  142.  
  143.    Each 4 octet TMux mini-header has the following general format:
  144.  
  145.                   | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
  146.                   +-------------------------------+
  147.                   |   Reserved    |  Length high  |
  148.                   +-------------------------------+
  149.                   |          Length low           |
  150.                   +-------------------------------+
  151.                   |         Protocol ID           |
  152.                   +-------------------------------+
  153.                   |          Checksum             |
  154.                   +-------------------------------+
  155.                   |      Transport segment        |
  156.                   |       ...                     |
  157.                   |       ...                     |
  158.  
  159.    The 'reserved' field is zeroed on output and ignored on input.
  160.  
  161.    The LENGTH field specifies the byte count for the transport seg-
  162.    ment, from 0-4095 octets.  For segments that are longer or
  163.    larger than the maximum TMux packet allowed (see section 4.1),
  164.    individual datagrams should be sent.
  165.  
  166.    The Protocol ID field contains the value that would normally
  167.    have been placed in the IP header Protocol field.
  168.  
  169.    The 'Checksum' field is the XOR of the first 3 octets.
  170.  
  171.    To ensure that TCP, UDP and other segments keep their 32 bit
  172.    alignment, where the segments being multiplexed are not a multi-
  173.    ple of 32 bits long, extra octets will be added to re-align the
  174.    end of the segment, and hence the next segment.  These octets
  175.    will be zeroed on output and ignored on input.  This padding
  176.    will not affect the LENGTH field, it will still contain the real
  177.    length of the segment.
  178.  
  179. 2.3. Sending Data
  180.  
  181.    Host endpoints may choose to use TMux at any time and in either
  182.    (or both) directions.  They also may switch between use of TMux
  183.    packaging and the usual individual packets for individual trans-
  184.    port associations.  The only barrier to the use of TMux is for
  185.    the sender to know whether TMux is supported by the receiver,
  186.    which is important, since early use of TMux is likely to be lim-
  187.    ited.
  188.  
  189.  
  190.  
  191.  
  192. Cameron, Crocker         Expires: April 94                 [Page 3]
  193.  
  194.  
  195.  
  196. Internet Draft                  TMux                   October 1993
  197.  
  198.  
  199.    The easiest way to achieve this is to only send TMux messages to
  200.    hosts from which a TMux message has already been received.  This
  201.    then leaves the problem of one host starting the TMux connec-
  202.    tion.  This is most easily accomplished by the host sending an
  203.    IP datagram with no data, but with a Protocol field value for
  204.    TMux.  This is referred to as a TMux ENQ message.  The host
  205.    receiving this message then knows that the originator supports
  206.    TMux, and can start to send TMux messages. This will in turn
  207.    cause the originator of the ENQ message to start to use TMux.
  208.    If for any reason the receiver does not intend to send TMux mes-
  209.    sages to the originator, but is prepared to accept them, then it
  210.    can reply with another ENQ message.
  211.  
  212.    If an ENQ message does not get a response, then it is reasonable
  213.    to resend the ENQ a while later in case the message was lost.
  214.    If this again is lost, the ENQ may be repeated as often as
  215.    needed, but the time between requests should increase exponen-
  216.    tially up to a limit of about 1 hour.  Suitable times between
  217.    ENQs would be 15 seconds, 30 seconds, 60 seconds, 120 seconds
  218.    etc.
  219.  
  220.    Note that this checking process does not need to impede any of
  221.    the transport (user) data, which may be sent as convenient,
  222.    albeit in its less-efficient small-packet form.
  223.  
  224.    The only problem with this scheme is that any host advertising
  225.    that it supports TMux, then stopping supporting it, will cause
  226.    any other hosts a problem.  The solution to this is to put a
  227.    Time To Live (TTL) value on a record of a host sending a TMux
  228.    packet, and expire it after a suitable time, eg. 1 minute.
  229.  
  230.    This is implemented as follows. When a packet that could be
  231.    TMuxed is to be sent to a host, a check is made to see if the
  232.    time to live has expired.  If so the host is marked as being
  233.    unable to TMux but the packet is still sent as a TMux packet. If
  234.    the host is really unable to TMux anymore (a rare occurrence)
  235.    then this packet will be timed out and retried by the transport
  236.    provider i.e. TCP and this time it will be sent as a normal
  237.    packet.  If the host is still able to TMux then it should send
  238.    back TMux traffic (even if it has been rebooted) and the local
  239.    host will mark it as able to TMux again. This removes any per-
  240.    formance problem of dropping out of TMuxing and having to send
  241.    probe messages.
  242.  
  243.  
  244. 3.  Protocol Behavior
  245.  
  246. 3.1. Transport Flow Control
  247.  
  248.    TMux operates as an extension to the IP datagram protocol.
  249.    Hence, it has no impact on most flow control mechanisms, since
  250.    they operate at the transport layer -- above TMux.
  251.  
  252.  
  253.  
  254.  
  255.  
  256. Cameron, Crocker         Expires: April 94                 [Page 4]
  257.  
  258.  
  259.  
  260. Internet Draft                  TMux                   October 1993
  261.  
  262.  
  263. 3.2. Connection Management
  264.  
  265.    The concept of a connection pertains to certain transport proto-
  266.    cols, but not to IP or to TMux.  Hence, when connection manage-
  267.    ment is required by a transport protocol using TMux, it occurs
  268.    in the same fashion as it does for IP.  In fact, the transport
  269.    protocol is not to be aware that TMux is being used.
  270.  
  271.  
  272. 3.3 Multiplexed Message Construction
  273.  
  274.    When a transport provider (eg. TCP or UDP) sends a packet, TMux
  275.    prepends that packet with a header to create a TMux message,
  276.    then appends the message to the Multiplexed Message under con-
  277.    struction.
  278.  
  279.    When the first message to be transmitted is placed into the Mul-
  280.    tiplexed Message under construction, a timer is started.  When
  281.    the timer expires, all outstanding message are placed into the
  282.    Multiplexed Message and this is transmitted. This ensures that
  283.    all messages constructed before the timer expires are sent in a
  284.    single Multiplexed Message.  If, during construction of the Mul-
  285.    tiplexed Message, the buffer holding the packet fills, the Mul-
  286.    tiplexed Message is transmitted immediately.
  287.  
  288.    The delay time should be user configurable; a reasonable time is
  289.    20 to 30 milliseconds.  The time period should be large enough
  290.    to give a reasonable probability of sending multiple packets but
  291.    not so large that the echo response time becomes a problem.
  292.    This suggests that the upper limit for the timer is probably
  293.    1/10th second.  As the cost of using timeouts on many systems is
  294.    quite large, it is recommended that a single timer be used and
  295.    that all connections are serviced on each expiry period.
  296.  
  297.    Additionally, configuration options may limit the number of
  298.    included data packets or the maximum size of the Multiplexed
  299.    Message before it is transmitted.  It is also suggested that
  300.    larger packets (eg those over 30 octets) should be sent as stan-
  301.    dard IP packets, and not multiplexed.  This is to ensure that
  302.    the delay used does not put a delay on those packets for which
  303.    it is inadvisable.
  304.  
  305. 4. Implementation Suggestion
  306.  
  307. 4.1 Maximum Packet Size
  308.  
  309.    In section 3.3, a note is made about sending packets immediately
  310.    if the limit on TMux packet size is reached.  On system where
  311.    Path MTU Discovery (as per RFC 1191) has been implemented this
  312.    should be used to discover the maximum packet size that can be
  313.    transmitted, and this should be used as the maximum TMux packet
  314.    size.
  315.  
  316.  
  317.  
  318.  
  319.  
  320. Cameron, Crocker         Expires: April 94                 [Page 5]
  321.  
  322.  
  323.  
  324. Internet Draft                  TMux                   October 1993
  325.  
  326.  
  327. 4.2 Deciding Which Packets to Multiplex
  328.  
  329.    It is the responsibility of the sender to decide which packets
  330.    should be TMux'd and which should not.  For example, packets
  331.    sent by FTP should not normally be multiplexed.  In many situa-
  332.    tions, it may be sensible to restrict the sessions that can be
  333.    multiplexed to just those involved in login traffic (TELNET and
  334.    RLOGIN) by examining the source and destination TCP port num-
  335.    bers.  However, if a segment that would not normally be multi-
  336.    plexed is to be sent and a TMux packet is already under con-
  337.    struction, then the extra segment can be added to the TMux
  338.    packet under construction, and this can then be sent immedi-
  339.    ately, rather than waiting for the timer to expire.
  340.  
  341. 5. Security Considerations
  342.  
  343.    Because TMux is effectively an extension to IP, it does not have
  344.    any more impact on site security than does IP.  Security should
  345.    be dealt with by upper layer protocols.
  346.  
  347.    Because some routers filter packets on the TCP port numbers, any
  348.    packets sent using TMux will not be subject to these tests.
  349.    Thus larger packets (sent as TCP segments) will be subject to
  350.    filtering, but smaller packets (sent via TMux) on the same con-
  351.    nection, will not be subject to filtering.  For this reason,
  352.    routers (that do not support TMux) which support this type of
  353.    filtering should not allow TMux packets through (in either
  354.    direction) to prevent this being a problem.
  355.  
  356. 6. Author's  Addresses
  357.  
  358.    P. Cameron
  359.    Xylogics International, Ltd.
  360.    Featherstone Rd.
  361.    Wolverton Mill
  362.    Milton Keynes
  363.    MK12 5RD
  364.    United Kingdom
  365.  
  366.    Telephone:      +44  908 222112
  367.    Fax:            +44  908 222115
  368.    Email:          cameron@xylint.co.uk
  369.  
  370.    D. Crocker
  371.    Silicon Graphics, Inc.
  372.    2011 N. Shoreline Blvd.
  373.    P.O. Box 7311
  374.    Mountain View, CA 94039-7311
  375.    USA
  376.  
  377.    Telephone:      +1 415 390 1804
  378.    Fax:            +1 415 962 8404
  379.    Email:          dcrocker@sgi.com
  380.  
  381.  
  382.  
  383.  
  384. Cameron, Crocker         Expires: April 94                 [Page 6]
  385.  
  386.  
  387.  
  388. Internet Draft                  TMux                   October 1993
  389.  
  390.  
  391. 7. Discussion List
  392.  
  393.    There is a discussion list for this protocol, which for histori-
  394.    cal reasons is called:
  395.  
  396.            cmp-id@xylint.co.uk
  397.  
  398.    Request to join the list should be sent to:
  399.  
  400.            cmp-id-request@xylint.co.uk
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448. Cameron, Crocker         Expires: April 94                 [Page 7]
  449.  
  450.